CheckoutSessions — PMO SFU#6353
Conversation
Committed-By-Agent: codex Co-authored-by: codex <noreply@openai.com>
Committed-By-Agent: codex Co-authored-by: codex <noreply@openai.com>
Committed-By-Agent: codex Co-authored-by: codex <noreply@openai.com>
| return !setupFutureUsageValues.isEmpty | ||
| } | ||
| return nil | ||
| case .checkoutSession: |
There was a problem hiding this comment.
Referring to line 133 here, can't select it.
For payment mode, it returns the top-level setupFutureUsage only. The setupFutureUsageString property is used in analytics. Is it intentional that this reports only the top-level value? I think this is consistent with others but just want to double check.
There was a problem hiding this comment.
Yes, I intentionally made it only report the top-level to align with intent flows
| waitForExpectations(timeout: 10) | ||
| } | ||
|
|
||
| func testCheckoutSessionConfirmWithNonCardPaymentMethodIncludesSavePaymentMethod() { |
There was a problem hiding this comment.
The tests in this PR are quite light considering what it's adding. Let's add PaymentSheetLPMConfirmFlowTests coverage: we already test PMO+SFU paymentIntentWithPMOSetupFutureUsagefor PI/deferred PI, but that suite doesn't test CheckoutSession+PMO SFU
|
|
||
| extension STPCheckoutSession { | ||
| var isPaymentMethodOptionsSetupFutureUsageSet: Bool { | ||
| return !setupFutureUsageForPaymentMethodType.isEmpty |
There was a problem hiding this comment.
Nit/question: The existing STPPaymentMethodOptions.isSetupFutureUsageSet (line 45-52 of STPPaymentMethodOptions.swift) checks whether any PMO entry contains the key setup_future_usage. Might be a bit safer to align with STPPaymentMethodOptions.
There was a problem hiding this comment.
Are you suggesting that we use the payment_method_options property on the checkout session as the data source for PMO SFU rather than setup_future_usage_for_payment_method_type or something else? If the former, I have a question about which to use down in the API team questions list, but for now my intuition is to use the setup_future_usage_for_payment_method_type property since it is specific to checkout sessions and what is used by web: https://stripe.sourcegraphcloud.com/deepsearch/c4c1b6ed-ecad-4140-a808-600a15fa1da9#answer-169850
STPTestingAPIClient+Swift.swift:198 warning: Unused function 'checkoutSessionAdditionalParameters(currency:amount:setupFutureUsage:paymentMethodOptionsSetupFutureUsage:allowPromotionCodes:allowAdjustableLineItemQuantity:includeShippingOptions:collectShippingAddress:collectBillingAddress:automaticTax:enableTaxIdCollection:adaptivePricingEnabled:customerEmailLocation:)'
STPTestingAPIClient+Swift.swift:292 warning: Unused function 'fetchCheckoutSessionPaymentMode(types:currency:amount:merchantCountry:customerID:setupFutureUsage:paymentMethodOptionsSetupFutureUsage:allowPromotionCodes:allowAdjustableLineItemQuantity:includeShippingOptions:collectShippingAddress:collectBillingAddress:automaticTax:enableTaxIdCollection:adaptivePricingEnabled:customerEmailLocation:)'This dead code check has been bypassed with the ℹ️ If this comment appears to be left in error, double check that the flagged code is actually used and/or make sure your branch is up-to-date with [find-dead-code] |
|
skipping dead code detection — fetchCheckoutSessionPaymentMode and checkoutSessionAdditionalParameters are used in testing code |
2 participants
Summary
Add PMO SFU support to CheckoutSessions
Note for testing: many payment methods have different PMO SFU options available as compared to Payment Intents
Motivation
https://docs.google.com/document/d/1CWglcOHR6I8cOWKjztPfnhnVG8axucpv-j5cWIoey7E/edit?pli=1&tab=t.g4karprubz63
Testing
Changelog